1. Field of the Invention
The present invention relates generally to distributed computing, which allows software applications to access resources distributed on a network. Specifically, the present invention relates to the use of syscall proxying to implement distributed computing for performing network penetration testing.
2. Related Art
Computer systems that are connected to a computer network, such as the Internet, must employ security measures to prevent unauthorized users from accessing these systems. The security measures must be properly designed and implemented in order to prevent unauthorized access. However, it is difficult to evaluate the effectiveness of such security measures, particularly in view of the increasing sophistication of techniques used to gain unauthorized access to computer systems.
The effectiveness of the security measures of a computer system may be evaluated by performing a computer security audit in which various aspects of computer security are analyzed and evaluated. The security audit may include a network penetration test, which is a process by which a security auditor attempts to gain unauthorized access to the computer system.
To be effective, the network penetration test must take advantage of certain characteristics of modern computer architecture, such as distributed computing. Although a great deal of work has been done in the distributed computing field and many techniques have been developed to provide the ability to distribute computing power among systems on a network, such techniques have not been optimized for use in network penetration testing.
The client/server model for distributed computing has been in use for several years. In this model, the client code is executed on a different computer than the server code. A widely accepted model for implementing client/server applications is the Remote Procedure Call method (RPC). In this model, both the client and server are programmed with special constructs and library calls to accommodate RPC. Typically, the procedures that are to be included in the RPC model are clearly specified by the developer. When one of these procedures is called in runtime, a request is built with the arguments of the called procedure, and this request is sent to the server program on the remote computer. The server program decodes the request, calls the requested procedure with the specified arguments and sends back the results to the client.
In RPC models, a lot of effort, symmetrically duplicated between the client and the server, is devoted both to converting back and forth from a common data representation format and to communicating through different calling conventions. These conversions make interoperability possible between a client and a server implemented in different platforms. Also, the RPC model attempts to attain generality, by making it possible to perform any procedure call across a network. However, in the conventional RPC model, knowledge of the intent to use RPC is required at development time. Typically, applications need to be re-written and re-built to be able to function with RPC. Thus, RPC is not suitable for scenarios in which such prior knowledge is not available, as in network penetration testing applications.
What is needed, when dealing with a family of procedure calls known as system calls (“syscalls”) and when interoperability among different platforms is not necessary, is a more simple system for executing syscalls through the network. Such a system would also allow for an application to transparently access remote resources without having to be reprogrammed. More specifically, in the field of network penetration testing, there is a need for such a system that can be implemented with a small server footprint.
As discussed above, penetration testing is the practice of testing the security of a computer system by attempting to actively compromise it. Attackers take advantage of vulnerabilities in software (programming errors or bugs that relate to security) in order to obtain control of their targets. The vulnerabilities that give the attacker the ability of executing arbitrary code in the target system are usually referred to as “code injection vulnerabilities.” Typical incarnations of code injection vulnerabilities are: buffer overflows and user-supplied format strings. Attacks for these vulnerabilities usually come in two steps:
(a) Injection vector (deployment). This portion of the attack is directed at exploiting the specific vulnerability and obtaining control of the target's processor.
(b) Payload. A piece of code to be executed once control is obtained.
A common piece of code used as attack payload is the “shell code,” which gives the tester the ability to have interactive control of the target system through a terminal after a successful attack. However, use of shell code has certain disadvantages, as it provides only a limited interface to the compromised computer. In certain situations, a command line shell might not be accessible or executable after successful exploitation, because, for example, the vulnerable application has dropped privileges, or the shell is running inside a limited environment.
Moreover, command line interface is only as useful as the applications it can access on the target system. If the tools needed by the tester are not already available on the target, then they will have to be installed. Installing additional software to a compromised computer alters the state of the tested system and raises the possibility of leaving the system in a worst security state than before the penetration test was performed. Indeed, such installations might not be permitted by the specific penetration testing rules in place. The present invention provides a major improvement in this area, as the target system does not have to be modified in order for the tester to be able to run his tools on it.